sasecurityfandomcom-20200214-history
MtuIssues
Category:Sasecurity back to http://scratchpad.wikia.com/wiki/Sasecurity TableOfContents from /SateLites/MtuIssues --- on moinmoin convert for zope IPcop } document lates If what Brendan is suggesting is true then you could use a Mikrotik router (demo mode should do it) to Mangle the packets to the required MTU see www.mikrotik.com > this is almost certainly an MTU issue. > For clients not connected directly to the gateway node you may see > problems (I did anyway ) with certain sat systems (Direcway 4020 in my > case which has an underlying MTU of 580) > > LW Knows about it for at least 6 months but has yet to resolve the > issue, don't hold your breath ! > > try setting the MTU on the gateway eth0 port to 580 and see if the > problem goes away (NOTE MTU of 580 may not be correct for your > particular setup) > > if that fixes it add the following line to the end of > * /etc/init.d/rc.local ifconfig eth0 mtu 580 > you only need to do this on the gateway > > We have a customer who is trying to access one of his suppliers web > > sites in order to order stock. Half way through the order he > > goes to a specific page and the page fails to successfully > > load. We have successfully accessed the page from a PC between > > our gateway node and the satellite link, and we can > > successfully access the site from an PC sat on the ethernet > > port of a meshbox (non gateway), however we can not > > successfully access the site if we connect to the same mesh > > box via a wireless ethernet bridge. > > > > My past experience , not with wireless, would suggest an MTU > > problem. > We have a customer who is trying to access one of his suppliers web > sites in order to order stock. Half way through the order he > goes to a specific page and the page fails to successfully > load. We have successfully accessed the page from a PC between > our gateway node and the satellite link, and we can > successfully access the site from an PC sat on the ethernet > port of a meshbox (non gateway), however we can not > successfully access the site if we connect to the same mesh > box via a wireless ethernet bridge. > > My past experience , not with wireless, would suggest an MTU > problem. > > > Comments and suggestions please. we have several issues of those kind in our deployments.... we investigate a lot and are now ready to shhare this exoperioence surely as we succeeded in reprioduce the issues and fix them. Observation: 1 - A gateway node directly connected in back2back eth with a sat modem and 3 repeaters linked wirelessly to the gateway. MTU hasn't been changed from the default The client A connected wirelessly to a repeater coulnd't surf very well . Tcp connection seems to be reseted and dropped or disconnected Client B is directly connected to the gateway in wireless. He has no issue to surf. all transfers are ok. leechtest from repeater nodes are failing in 90% of the time after transfering several kb. leechtest on gateway node are okay. Investigations: A datagrams analysis on the gateway , repeater and clients are showing a fragmentation problem whit client A. However no fragmentation problem with client B... In looking deeper, we saw the gateway was loosing ipfrag_time bits in datagrams when natting from wireless tunnels to the eth. Deeper again we understood the problem was in ipfrag bits stacks and NAT + TUNNELS. When Client A (connected in wireless repeater) is surfing on the net, his datagrams are encapsulated in TUN0 interface with a MTU change from 1500 (Wlan0 interface) to 1450 (TUN0), then going through the Tunnel toward the gateway. At this time datagrams is supposed to be translated in the eth0 address (NAT rules) of the gateway and then changing the MTU from 1450 to 1500... We noticed then when we add a passive or active network equipment between the gateway and the modem (eg: hub, switch, router or a Linux IPCop distro) it fixes the problem. Which means there is definitivly a problem with NAT/fragmentation causing some MTU problems on a gateway node directly connected in a Sat modem or in back to back eth connection eg: (MESHNODES <-- wireless links --> MESH GATEWAY <--eth cross-cable back2back--> MODEM) ...... Jérémy Lacroix -- Linux-Services Déploiement réseaux sans fils / logiciels libres / création web tel: 0870 21 4312 -- http://www.linux-services.fr/ > "Wireless" > > What I fail to see with Bredons suggestion, but I've not tried it yet, > is why the mtu on the gateway node would effect what is happening > on a remote node, and why on the remote node its works on the ethernet > but for wireless clients, unless there is some pmtu discovery stuff at > work. But as I said this does look like an mtu problem, although I > would have thought that if a wireless mtu problem existed we would see > it on intermesh boxes links because of the overhead of the tunnels and > encryption. Whilst I agree that it does not seem entirely logical that this should fix the issue, in my setup it did, I think that information concerning fragmentation isn't always getting passed back down the mesh and there may indeed be some PMTU issues. Since details of what happens in the mesh and how the various locustworld scripts configure everything is not well documented it's hard to make a complete diagnosis. I don't see why one would need to add a router (or why this would automatically help ) since the MTU can be set at the gateway, manually for testing then automatically on boot by adding the line * ifconfig eth0 mtu 580 * to the end of * /etc/init.d/rc.local this 'fix' will be broken any time you update the version using getandverify Why, if it's not a LWmesh issue do I not have any problems with my Staros links off this system or over my wired ethernet one other issue for us poor satellite victims is the need for the DNSchains to be set up so that we are using the Sat provider's proxyed DNS server instead of the locustworld one iwcconfig frag }